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(54) Inter-object communication method 



(57) A method for converting an interface definition 
description and an inter-object communication method, 
in which a service provider can control a message deliv- 
ery m^od to realize communication based not on 
object designation but on service designation. In the 
methods, a client stub (1c), a server skeleton (2s) and a 
routing program (1r.2r) are generated from an interface 
definition defined by the service provider. A client object 
(10) calls the client stub, and sends a message whose 
send destination is spedf ied by an interface name. The 
server skeleton registers a provided service in a routing 
infomrvatlbn table (31). A router (12.22) determines a 
server ol)ject (20) as the send destination on the basis 
of a routing program assodated with the interface name 
of the send message, a message queue information 
table (30) and the routing Information table (31), and 
sends the message. 
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Description 

BACKGROUND OF THE INVENTION 

The present invention relates to an inter-object s 
communication method in an application which uses a 
plurality of objects to be operated on a single computer 
or on a plurality of computers connected In a network 
and more parlicutarly. and also relates to a method for 
converting an Interface definition in such an application. 10 

Ck)nventional inter-object communication method in 
an application which uses a plurality of objects to be 
operated on a single computer or on a plurality of com- 
puters connected in a network, includes a common 
object request broker architecture (CORBA)(Archrtec- is 
ture and Specification Revision 2.0, July 1995. OMG) in 
the Object Management Group (OMG). In the CORBA. 
when interface definition language (IDL) is used, an 
object interface can be defined independently of a pro- 
gramming language for describing the objects. 20 

When an interface definition desaibed in the IDL is 
converted by an IDL compiler, there are automatically 
generated a cfient stub (term often used in the above 
CORBA) assodated with a client program to play a role 
in sending a message from the client program to a 2S 
server program as well as a server skeleton (term often 
used in the above CORBA, which is also a template for 
processing description) corresponding to a description 
part of the server program other than an original 
processing desalptlon part thereof, thus enabling relief so 
of programmer's burden. 

Actual commurncation between the programs is 
carried out on the basis of the object request broker 
(ORB) technique. 

The client program searches for a communication 35 
destination object on the basis of the name, acquires as 
its searched result an object reference (which is infor- 
mation indicative of the presence location of the object 
(server program)) associated with the server program 
con-esponding to the object in a one-to-one relationship: 40 
vtrhereas. the client program transmits a message to the 
sender program by calling a client stub generated from 
the interface associated with the object reference. 

Thereby a programmer of the client program can 
describe the originaliDrocessing desaiplfon part of the 45 
application program without recognizing the physical 
position of the sender program a the actual protocol. 

Meanwhile, a programmer of the server program Is 
only required to describe only the original processing of 
the application program without recognizing tiie actual so 
communication protocol. 

SUMMARY OF THE INVENTION 

H is therefore an object of the present invention to ss 
provide a programming method centered on the original 
processing (service) provided by a server object while 
securing the above advantages of a CORBA. and also 



to provkie an inter-object communk:ation method. 

The object includes five sd^-objects whk:h follow. 

First one of tiie sub-objects is to enable communi- 
catfon with the server object whk^ provides a sen^ 
witfiout any need for specifying the object itself, by 
specifying the service. 

Second one of the sub-objects is to suitably deliver 
a communication message to tiie sender object which 
provides the service. 

Third one of the sub-objects is to eliminate ttie need 
for modifying the dient object at ttie time of adding, 
deleting or modifying the server object which provides 
tiie sendee. 

Fourth one of the sub-objects is to enatile the s;ecv- 
\ce provider and the programmer of the server o^|(fto;' 
control the message distribution method. 

Fifth one of the sub-ot3jects is to centralizedly man- 
age a program module associated with one applfoation 
to simplify its installing operation. 

In accordance with an aspect of tiie present inven- 
tion, tiie above objects can be attained by providing a 
method for converting an interface definition description 
in an inler-objecl communication system wherein a cli- 
ent object operatwig on eitiier one of a plurality of com- 
puters in a networic or on a single computer sends a 
message to a server ot)ject operating on the same or 
another computer to execute a predetermined process- 
ing operation. 

In this Invention, the metiiod includes tiie step of 
causing an Interface definition converting program to 
convert the interlace definition description descriljed in 
an HTterface definition language to thereby generate a 
client stub, a sen/er skeleton and a routing program. 
The interface definition description includes one or 
more of data necessary for tiie predetermined process- 
ing operatfon, a method definitfon description of a 
processing result, and a message description for speci- 
fying a format of ttie message to be sent in response to 
tiie method definitkKt description. The dient ^b is 
called to cause the client object to send tt>e message. 
The server skeleton indudes a server registration 
metiiod for storing, in routing information memory 
means, routing information for specifying the format of 
tiie message whk:h the server object itself can process 
when started and also Includes a method for describing 
the predetermined processing operation to be executed 
when tiie server ot^ect receives the message. The rout- 
ing program judges whether or not the processing of the 
server object assodated with the routing information of 
tiie message is possifcrfe through comparison between 
the message and the routing information. 

In accordance with another aspect of the present 
Invention, there is provided an inter-object communica- 
tion system wherein a dient object operating on either 
one of a plurality of computers in a network or on a sin- 
gle computer sends a message to a server object oper- 
ating on the same or another computer to execute a 
predetermined processing operation. In this method, a 
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client stub» a server skeleton and a routing program 
generated through the above conversion are stored in 
the computers. When the server object is started, a 
server registration method is called and routing informa- 
tion is stored in routing Information memory means to 
cause the client object to call the client stub to send the 
message and to hold the sent message in a send mes- 
sage queue. A router extracts the message from the 
send message queue, to determine a send destination 
object according to the routing program and to add the 
received message in a receive message queue associ- 
ated with the send destination object. The server skele- 
ton extracts the message from the receive message 
queue ^ the sender object executes the predeter- 
mined processing operatfon of the message extracted 
by the server skeleton. 

In the method, the routing program adds a queue- 
ing option desaiptk)n including a message nriaximum 
number designation and a queueing time designation to 
a message description of the interlace definition 
description, compares the message and the routing 
information to judge whether or not the processing oper- 
atton by the server object associated with the routing 
information of the message is possible and. in the case 
of presence of the message maximum number designa- 
tion, performs the queueing option judging operation. 

In the inter-object communication system, the 
router keeps the message extracted from the send mes- 
sage queue In a temporary keep message queue, and 
when another message has the same contents as the 
kept message, the router integrates the messages into 
a single message, and when the number of messages 
within the temporary keep message queue exceeds the 
message maximum number or when the queueing time 
elapses after the message is queued, the router adds 
the message to a receive message queue associated 
with the send destination object. 

In the method, in place of the routing program, such 
a custom routing program is generated as to compare 
the message and the routing information to judge 
whether or not the processing operatfon by the server 
object assodated with the routing infonnation of the 
message is possible and to perform the matching option 
judging operatfon. 

In the inter-object comnwnicatfon system, further, 
the client stub, the server skeleton and the routing pro- 
gram are combined into a single server object to store 
the service object in a service object memory means; 
the server object is extracted from the service memory 
means to call the dient stub before the dient object 
sends a message; the server object is extracted from 
the service memory means to call the routing program 
before the router determines the send destination 
object; and the server object is extracted from the serv- 
ice memory means to call the server skeleton at the 
time of starting the server object. 



BRIEF DESCRIPTION OF THE DRAWINGS 

Fig. 1 shows a general arrangement of an embocft- 
ment of the present invention; 
s Rg. 2 shows a structure of an IDL compiler and a 
relationship thereof with an interface definition file, 
a client stub, a server skeleton, a routing program; 
Fig. 3 is a flowchart for explaining how to generate 
the dient stub; 

10 Fig. 4 is a ffowchart for explaining how to generate 
the server skeleton; 

Fig. 5 is a flowchart for explaining how to generate 
the routing program; 

Fig, 6 shows an exemplary structure of the interface 
75 definition file; 

Ftg. 7 shows an exemplary structure of the dient 
stub; 

Fig. 8 shows an exemplary slaiclure of the server 
skeleton; 

20 Fig. 9 shows an exenplary structure of the routing 
program; 

Fig. 10 shows a structure of a message queue; 
Fig. 1 1 is a structure of a message queue informa- 
tion table; 

25 Ftg. 12 shows a structure of a routing information 
table; 

Fig. 13 is a ffowchart for explaining a client stub 
process; 

Fig. 14 is a flowchart for explaining a server skele- 
30 ton process; 

Fig. 15 is a ffowchart for explaining a routing proc- 
ess; 

Fig. 16 shows an arrangement of an inter-object 
communfoation system using a dynamic service 
35 object toader; and 

Fig. 1 7 shows a stmcture of a sender ok)ject. 

DESCRIPTION OF THE PREFERRED EMBODI- 
MENTS 

40 

An embodiment of the present invention wiH be 
detailed below with reference to the drawings. 

Refen-ing first to Fig. 1, there is shown an entire 
arrangement of an embodiment of the present inven- 
45 tion. 

In the present emljodimenf, computers 1, 2 and 3 
are conneded in a network 8. 

A dient object 10 as a program for requiring a serv- 
k:e to a server is present in the computer 1. and, a 
50 server object 20 as a program for executing a service in 
response to a request from a client is present In the 
computer 2 independently from each other. 

In the inter-objed communication of the present 
invention, however, it is possible that a dient objed 10 
55 and the server object 20 are both present in the same 
computer 6 as shown in Fig. 16. and it is also possible 
that a plurality of client objects 10 and a plurality of 
server objeds 20 are mixedly present in a single com- 



25 



30 



3 



5 



EP0 860 776A1 



6 



puter. 

In addition, H is also possible to place a nnenwy 3m 
of the computer 3 in the computer 1 or 2. 

Fig. 2 schematically shows how to generate a client 
stub 1c tor sending a message from the client program s 
to the server program, a server skeleton 2s tor serving 
as a template for processing desaiption of the server 
program, and a routing program 1r for judging whether 
or not the service can be processed by the server object 
on the basis of the received message, from an interface io 
definition file 4 prepared in an Interface definition lan- 
guage (IDL) by a service provider with use of an inter- 
face definition conversion program 5 (IDL compiler 5). 

The IDL compiler 5 includes a lexical analyzer 50, a 
parser 51 , a client stub generator 52, a server skeleton is 
generator 53 and a routing program generator 54. 

The lexical analyzer 50 analyzes a token while 
reading the interface definition file 4 and provides infor- 
mation on the read token to the parser 51 . 

The parser 51 performs its analyzing or parsing 20 
operation using the above information and calls the cli- 
ent stub generator 52, server skeleton generator 53 and 
routing program generator 54. 

Shown in Fig. 6 is a structure of an example of the 
interface definition file. 25 

The interface definition file 4 is a further extension 
of the IDL description used in the CORBA. 

The Interface definition file 4 has a native method 
desaiption 40 for calling an external method, and 
method definitions 41 and 42 corresponding to services 30 
provided by the server object. 

The method definition 41 has a method declaration 
(corresponding to a descriptton "Void search... Excep- 
tion" given under Method Definition 1) used in the 
CORBA. a message description 410 and a matching 35 
option description 411 fa performing a strict matching 
operation t)ased on user's irtstruction as an option. 

The matching cptton description 41 1 1s descrtoed in 
a language independent torntat as in the case where 
the CORBA IDL description is language-independent. 40 

The example of Fig. 6 shows the message descrip- 
tion 410 indicating that a communication message has 
a pattern of ''search $keyword*, where a token starting 
with $ is a parameter. 

The matching option description 411 is one whfch 45 
judges whether or not the parameter "$keyword" can be 
processed with use of the method IsSupportCate- 
goryO" declared in the native method description 40. 

The message descriptton 410 may include a 
queueing option description 4100 as an option. so 

In the example of Fig. 6, the maxinxim nunnber 
'maximum' of messages handleabie in the message 
integrating operation is specified to be 100, and the 
longest message queueing time is specified to be 60 
seconds. 55 

The message integration will be described later. 

Fig. 7 shows a structure of an example of the client 
stub compiled and generated by the IDL compiler from 



the interface definition file 4 shown in Fig. 6 as an exam- 
pie. The generated dient stub 1c is described in source 
level language In the example of Fig. 7, C++ is used as 
a programming language after the compilation. 

The client stub 1c in compiled code is prepared by 
compifing a clierrt stub header f ile 1d1 and a dient stub 
source fOe1cf2. 

The dient stub header file 1cf1 indudes messaging 
method dedarations Icfll and 1d12 called by the di- 
ent object 10. 

Ihe dient stub source file 1d2 ffidudes messaging 
method definitions 1cf21 and 1cf22. 

Shown in Fig. 3 is a flowchart for explaining a dient 
stub generating process by the client stub generator 52. 

A cfient stub generating process 520, when called 
by the parser 51, analyzes the interface definition file 4 
sequentially from the metfiod definition 41 ttierein» 
repeats its subsequent processing operations on the 
basis of a judgement step 521 on whether or not tiiere 
is a method definition, and If ttiere is no definition, termi- 
nates its operation at an end step 527. 

In compiling ttie method definition 41 , at a messag- 
ing method dedaration code generation step 522, tiiere 
are generated the messaging metiiod declaration 1cf1 1 
and a protocol type dedaration part (which corresponds 
to ''void DigitalLbrary... Exception' given betow the 
Messaging Method Definition. The declaration part in 
the C++ language is also called a prototype declaration 
parf) of the messaging method definition 1cf21. 

Next, at a message pattern string definition code 
generation step 523, codes for preparation of a mes- 
sage string not containing a parameter are generated m 
tiie messaging metiiod definition IcQI. 

When a parameter Is present in the message string, 
tfie system repeats tiie operation of a parameter setting 
code generatton step 525 on tiie k)asis of a judgement 
result of the step 524 indicative of tiie presence of 
absence of a parameter. At tiie parameter setting code 
generation step 525. tfie system generates In tiie mes- 
saging method definition 1cf21 codes for addition of a 
parameter string to tiie above message string. 

Rnally. at a message sending code generation step 
526. the system generates in the messaging method 
definition 1cf21 codes for calling of a message sending 
function of a message communication library 11 (see 
Fig. 11) witti use of an interface name ("'DigitalLibrary") 
and tiie message string as parameters. 

Rg. 8 shows a structure of an example of tiie server 
skeleton compiled and generated by tiie IDL compiler 
from tiie interface definition file 4 of Rg. 6. The gener- 
ated server skeleton 2s is ctescrlbed in source level lan- 
guage. Even in the example of Rg. 8. C++ is used as a 
programnrting language after the compilation. 

The server skeleton 2s in compiled code is gener- 
ated by compiling a server skeleton header file 2sf1 and 
a server skeleton stub source file 2sf2. 

The server skeleton header file 2sf 1 includes a reg- 
istration method dedaration 2sf 1 0 to be called for regis- 
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tration oi the server object 20 in the routing inlornnation 
table (see Fig. 1) at the time of activating the server 
objecl 20 and messaging handler declarations 25f11 
and 2sf12. 

The server skeleton stub source f lie 2sf2 includes a 
registration method definition 2sf20 and messaging 
handler definitions 2sf21 and 2sf22. 

Fig. 4 is a flowchart for explaining tiie operation of a 
server skeleton generation process 530 by the server 
skeleton generator 53. 

The server skeleton generation process 530 Is 
cailedby the parser 51. 

At a registration method declaration code genera- 
tion step 531, the system generates the registration 
method declaration 2sf10 and a prototype declaration 
part (corresponding to DigitaL.registerO" given 
bebw the Registration Method Definition) of the regls^ 
tration metiiod definition 2sf20. 

At a server registration code generation step 532, 
the system generates in the registration method defini- 
tion 2s120. a code for registration of the server object 20 
(refer to Fig. 1) in the routing information table (refer to 
Fig. 1) with use of the interface name ("DigitalLibraryT 
as an argument. 

Next, the system analyzes the metfiod definition 41 
of the Interface definition file 4 (refer to Fig. 6) sequen- 
tially» repeats the subsequent operations on the basis of 
a judgement result of a step 533 of judging the presence 
or absence of a method definition, and In the absence d 
a definition, terminates its operation at an end step 536. 

At a message handler declaration code generation 
step 534. the system generates the messaging handler 
declarations 2sf 1 1 and 2sf12 as well as prototype dec- 
laration parts (corresponding to Void DigitaL... keyword" 
given below Message Handler Definitions 1 and 2) of 
the messaging handler definitions 2sf21 and 2sf22. 

Described in a body of the message handler defini- 
tion are the original c^ations of services provkJed by 
the server object. The original operations are described 
by the programmer of the server object 

At a message handler registration code generation 
step 535. the system generates in registration method 
definition 2sf20, a code for registering in a message 
communication library 21 (refer to Fig. 1) a character 
string con^espondlng to a conversion of parameters 
specified in the message descriptk)n 410 into a stand- 
ard representation based on predetermined rules as 
wen as a message handier as arguments. 

Fig. 9 is a structure of an example of the routing 
program compiled and generated by the IDL compiler 
from the interface definition file 4 shown in Fig. 6. The 
generated routing program 1r is desaibed in source 
level language. Even in this example. Gi-+ is used as an 
example of the programming language after the compi- 
lation. 

The routing program 1r is generated by compiling a 
routing program header file Irfl and a routing program 
source file 1rf2. 



The routing program header file Irfl has an inter- 
, face name variable declaration (caresponding to 
"static InterfaceName" given betow the Routing Pro- 
gram Class Deciaratbn. a queuing option variable dec- 
5 laration Irfll compiled from the queueing option 
description 4100 (see Fig. 6). and a matching method 
declaration Irf 12 to be called by a router 12 (see Rg. 1). 

The routing program source file 1r12 has an inter- 
face name variable declaration (corresponding to 
10 "static "Di^talUbrary"" given below the Routing Pro- 
gram Glass Definition), an external metinod declaration 
1 rf20 compiled from the native method descr'f>tion 40. a 
queuing option variable definition 1ri21 and a matching 
method definition 1rf22. 
15 Shown in Fig. 5 is a flowchart for explaining the 
operatkm of a routing program generation process 5400 
by the routing program generator 54. 

The routing program generation process 5400 is 
called by the parser 51 . 
20 At an interlace name variable code generation step 
5401, the system generates a code for initialization of 
an interface name variable (corresponding to the above 
interface name variable definition). 

Next, ttie system judges at a judgement step 5402 
25 the presence or absence of an external method declara- 
tion. In the presence of an external method declaratk>n» 
the system generates at an external method declaration 
code generation step 5403 the external method decla- 
ration 1rf20 compiled from the native method descrtp- 
30 tion 40. 

Regardless of the judgement results of the judge- 
ment step 5402, tiie system judges at a judgement step 
5404 the presence or absence of a queueing option 
description. In the presence of a queueing option 

35 description, the system generates the queuing option 
variable declaration Irfl 1 compiled from the queueing 
optkKi description 4100 and the queuing option variable 
def inition 1rf21 at a step 5405 of generating a queueing 
option variable designation value setting code. 

40 Regardless of the judgement result of the step 
5402» the system generates at a step 5406 of generat- 
ffig a matching method declaration code the matching 
method declaration 1rf12 and a prototype declaration 
part (corresponding to 1x)olean....message'' given 

45 below the Matching Method Def inition) of the matching 
method definition 1rf22. 

Next, at a message pattern comparison code gen- 
erating step 5407, the system generates in the match- 
ing method definition 1rf22, a code for computing a 

50 character string corresponding to a conversion of a 
parameter of the message pattenn specified m tiie mes- 
sage description 410 into a standard representation 
based on predetermined rules with a message as an 
argument of tiie matching method definition 1rf22. The 

55 system generates a code for returning a 'false' indk:ative 
of a failure when a coirx;kJence therebetween is not 
found. 

Finally, the system judges tiie presence or absence 
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of a matching option desaiption at a judgement step 

5408 and. in some cases, generates in the matcNng 
method definition 1r122 a code conesponding to a con- 
version of the matching option description 41 1 at a step 

5409 of generating a matching option desaiption exe- 
cute code. The routing program in the presence of the 
matching description is called a custom routing pro- 
gram. 

Regardless of the judgement result at the judge- 
ment step, the system terminates the operation of the 
routing program generator 54 at an end step 5410. 

Fig. 10 shows a structure of a message queue. 

A send message queue 1m1, a receive message 
queue 1m2. a transferring send message queue 1m3, a 
temporary keep message queue Im4. a send message 
queue 2m1, a receive message queue 2m2, a transfer- 
ring send message queue 2m3 and a temporary keep 
message queue 2m4. shown in Fig. 1 have different use 
purposes but all have such a message queue structure 
as shown in Fig. 10. 

The send message queue 1 ml includes a message 
queue ID ImlO for uniquely identifying a message 
queue and messages lmli and iml2. 

The message 1 ml 1 in turn has a send destination 
message queue ID lmli 0 indicative of send destina- 
tion ot>jects. a send origination message queue ID list 
1m111 indicative of send origination objects, an inter- 
face name 1ml 12 of a service which the send origina- 
tion dtiett is to use. a message body data Imll3 
indicative of a body of the message, and queuing time- 
out time 1ml 14. 

When consideration is paid to a case of such mes- 
sage integration as will be described later, there exist a 
plurality of such send originatwn objects, to which end 
the send origination message queue ID list 1 ml 1 1 has 
a message queue ID 1 ml 1 1 1 and a message queue ID 
lmli 12. 

Rg. 11 shows a structure of a message queue 
information table 30 (see Fig. 1). 

The message queue information table 30 includes 
message queue information items 301 and 302. 

The message queue information item 301 has a 
message queue ID 3010 and a computer address 301 1 
indicative of an address of a computer having the mes- 
sage queue present therein. 

Fig. 12 shows a structure of a routing information 
table 31 (see Rg. 1). 

The routing information table 31 includes interface 
information itenrts 311 and 312 corresponding to serv- 
ices provided by the server object. 

The interlace information item 31 1 has an interface 
name 3110, a routing program designation data 3111 
indicative of a routing program which the router uses for 
determining a message transfer destination, and a 
server object table 31 12 indicative of the server object 
20 supporting the interlace. 

In the present invention, a plurality of the server 
objects 20 can be present to support a single interface. 



to which end the server object table 3112 has message 
queue IDs 31121 and 31122 of the receive message 
queues 2m2 of the server objects 20. 

Shovwi in Fig. 13 is a flowchart for explaining the 
5 operation of a client stub process 1 caO by the client stub 
1c. 

Ihe client stub process IcaO is called by the client 
object 10. 

At a message string generation step 1 cal . the sys- 

10 tern generates a message string corresponding to a 
method called fc>y the client object 10. 

At a message pattern parameter setting step 1ca2. 
the system sets an argument passed to the method for 
the message string as a parameter. 

15 At a step 1ca3 of setting the interface name of the 
message and the message queue ID, the system sets 
the message queue ID 1m10 of the dient object for the 
message queue ID 1 ml 1 1 1 , sets the interface name for 
designation of a send destination of the message for the 

20 interlace name 1 ml 1 2, and sets the message string for 
the message body data 1 ml 13 to thereby prepare the 
message 1m11. 

Rnally. at a step lca4 of storing a send message 
queue of the message, the system sets the prepared 

25 message lmli for the message queue 1m1 and then 
terminates Its operation at an end step 1ca5. 

Referring to Fig. 14, there is shown a flowchart for 
explaining the operation of a server skeleton process 
2sa0 by the server skeleton 2s. 

30 The server skeleton process 2sa0 is called by the 
message communication library 21. 

At a step 2sa1 of registering the routing information 
table of the interface name and message queue ID, the 
system searches the routing information fable 31 for the 

35 interface name which the server object 20 supports on 
the basis of such an interface name 31 10 as the inter- 
nee informatk)n item 311 withm the t^e. and when 
finding the interface name, the system registers the 
receive message queue 2m2 of the server object 20 In 

40 the server object table 31 12 as the message queue ID 
31121. 

At a step 2sa2 of registering the message pattern 
and message handler, the system registers in a mes- 
sage communication library the messaging handler def- 

45 inition 2sf21 and a message pattem fbr starting the 
message handler thereof. 

At a step 2sa3 of acquiring a message from the 
receive message queue, the system extracts the mes- 
sage 1m1 1 from the receive message queue 2m2. 

50 The system next compares the message body data 
1 ml 13 of the message 1m1 1 with the message pattern 
to judge the presence or absence of the message han- 
dler at a step 2sa4. and in the case of the absence of 
the message handler, the system terminates its opera- 

55 tion at an error end step 2sa5. 

In the presence of the message handler, the system 
calls the message handler with use of the parameter 
extracted from the message as an argument at a mes- 
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sage handler starting step 2sa6. 

Thereafter, the system repeats at a step 2sa3 the 
operation of acquiring the message from the receive 
message queue. 

Fig. 15 shows a flowchart for explaining the opera- 
tion of a message routing process by the routing pro- 
gram 1r. 

First of all. at a step 1 ra01 of acquiring the interface 
name of a head message of a send message queue, 
the routing program 1 r selects one message 1 ml 1 to be 
delivered and acquires its interface name 1m1 12. 

At a step 1ra02 of judging the presence or absence 
of the acquired interface name 1 mil 2 in the routing 
information table, the system searches the routing infor- 
mation table 31 for the interlace name 1m112 on the 
basis of such an interface name 3110 as the interface 
information item 31 1 within the table. 

if falling to find the interface name, at a step 1 ra03 
of storing an error message in the corresponding send 
queue, the system stores the error message in the 
receive message queue 1m2 and goes to the step 
IraOl to acquire the interface name of the head mes> 
sage of a send nrtessage queue. 

If finding the interface name 31 10. at a step 1ra04 
of calling the matching method fa the routing program, 
the system calls the matching method 1rf22 of the rout- 
ing program 1r specified by the routing program desig- 
nation data 31 1 1 with use of the message body data 
1 ml 13 as an argument. 

On the basis of the called result, the system deter- 
mines at a step 1ra05 of judging whether or not the 
matching is successful, the system determines whether 
or not the determination of a delivery destination is suc- 
cessful. 

If failing to determine the delivery destination, the 
system goes to the step Ira03 to store the enror mes- 
sage in the corresponding receive queua 

If finding the delivery destination, at a step 1ra06 of 
storing a message in a temporary keep message 
queue, the system stores the message Imll In the 
temporary keep message queue 1m4. 

At this time, the system stores the nr^essage queue 
ID 31121 of the server object table 3112 in the send 
destination message queue ID imll 0 within the mes- 
sage Imll. and stores in the queuing timeout time 
1m1 14 a time corresponding to an addition of the time- 
out time specified in the queuing option variable defini- 
tion 1rf21 to the storage time. 

Further, at a step 1 ra07 of judging the presence or 
alDsence of the message queue ID. the system performs 
the operation of the step 1ra06 of storing the message 
in the temporary keep message queue when finding the 
presence of the message queue ID 31122 within the 
server object table. 

In the absence of the message queue ID, the sys- 
tem goes to a step 1ra08 to judge the presence or 
absence of queuing designation. 

The queueing designation, which is a parameter 



designation relating to the message integration, uses 
the value of the queuing option variable definition 1r!21. 

The definitk>n value is 0 by default, in which case 
the system regards it as no queuing designation and 

5 performs no message integration arxi goes to a step 
Iral 1 to judge the presence or absence of messages. 

In the presence of the queuevig designation, tiie 
system judges whether or not the number of messages 
reaches its maximum. 

10 The number of nrtessage queue IDs within the send 
origination message queue ID list 1m1 1 1 of the tempo- 
rary keep message queue 1m4 con-esponds to the 
number of integrated messages. Thus, when the ID 
nunrt^er is larger than the designated maximum nurnber, 

15 the system goes to the step trail tojudge the presence 
or absence of messages. 

In the case of absence of messages, the system 
judges whether or not the timeout tnTie expired. 

When the cunrent tinrie goes behind the timeout time 

20 1m114, the system goes to the step trail tojudgethe 
presence or absence of messages. 

In the case of the message absence, the system 
goes to the step iraOl to acquire the interlace of the 
head message of a send message queue for process- 
es ing of the next message. 

At the step trail of judging the presence or 
absence of messages, the system searches for the tem- 
porary keep message queue 1m4 and. when the time- 
out time 1mll4 of the message 1m11 expires, the 

30 system goes to a step iral 2 to judge whether or not the 
computer addresses are the same. 

If there is no message whose time is behind the 
timeout time, the system goes to the step IraOl to 
acquire the interface of the head message of a send 

35 message queue for processing of the next message. 

At the step 1 ral 2 of judging whether or not the com- 
puter addresses are the same, the system compares 
the send destinatfon message queue ID ImllO of the 
message Imll with the message queue ID 301 0 stored 

40 in the message queue infomnation 301 and 302 of tine 
message queue information table 30, and acquires the 
computer address 3011 of the coincided message 
queue information 301. 

When the computer address 301 1 is not the current 

45 computer address, the system goes to a step IralS to 
transfer to the transferring send message queue of 
another computer, and for example, the system trans- 
fers the message 1m11 to the transferring send mes- 
sage queue 2m3 of the computer 2. 

so Regardless of the above judgement result, the sys- 
tem proceeds to a step 1ra14 to transfer a message to 
the next corresponding receive message queue. For 
example, the router 22 transfers the message 1m1 1 to 
the receive message queue 2m2 corresponding to the 

55 send destination message queue I D 1 ml 1 0. 

Thereafter, in order to process another message 
within the temporary keep message queue 1m4, the 
system repeats the operation of the step 1 ral 1 to judge 
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the presence or absence of a message. 

The embodiment of the present invention has been 
explained above. Another embodiment thereof will be 
explained in detail below. 

Rg. 17 shows a structure of a server object 70 for s 
centralizedly managing several programs for services. 

The service object 70 includes an interface name 
700. the client stub 1c, server skeleton 2s and routing 
program 1r in the foregoing embodiment 

Shown in Rg. 16 is an arrangement of an Inter- io 
object communication system which uses a dynamic 
service object loader for causing the client object 10, 
sen/er object 20 and router 22 to load the service object 
of Rg. 17 as necessary. 

In the present anrangement, dynamic object service is 
loaders 6d1 , 6d2 and 6d3 and a memory 7m for storing 
the service object 70 therein are additbnally provided in 
the entire arrangement of the foregoing embodiment. 

The dynamic object service loader 6d1, wNch is 
called by the client object 10. dynamically loads the 20 
service ot^ect 70 and passes the client stub 1c to the 
client object 10. 

Thereafter, the client object 10 utilizes the client 
stub 1c as in the foregoing embodiment. 

Even the dynamic object service loader 6d2 and 25 
6d3 also each perform similar operations in the server 
object 20 and router 22. 

The memory 7m may be placed on the computer 6 
or 3 if necessary. 

The present invention has for example the following so 
six advantages (1) to (6) in accordance with the afore- 
mentioned method. 

(1) When the client object designates the interface 
name for its communication, the service can be 3s 
used without explicitly designating the server 
object 

(2) TTie object which provides the service is not 
always single. When the router delivers a message 

to a plurality of communication destinations, one-to- 40 
multipoint communication can be realized without 
the programmer of the client object recognizes it 

(3) Even when the object which provides the serv- 
ice is added, deleted or changed, the message can 

be delivered without causing the router to affect the 45 
client object, by the server object causing to suita- 
bly update the routing information (relating to the 
service provided by its own). 

(4) When the service provider or the programmer of 
the server object customizes the routing method for so 
causing the router to determine the communication 
destination, finer message delivery control can be 
realized. 

(5) When the service provider or the programmer of 

the server object specifies a method for causing the 55 
router to integrate messages having the same con- 
tents, the amount of messages can be recftjced and 
thereby the load of the sen/er object can be 



reduced. 

(6) When the client stub, server skeleton and rout- 
ing program are combined into a single service 
object so that, at the time of execution, the client 
object, server object and router will dynamically 
load the service object respectively: the program 
nxxiules can be centralizedly managed and appli- 
cation installation can be simplified. 

Claims 

1. A method for converting an irrterface definition 
description In an inter-object communication sys- 
tem wherein a client object (10) operating on either 
one of a plurality of computers (1,2.3) in a network 
(8) or on a single computer sends a message to a 
server object (20) operating on the same or another 
computer to acecute a predetermined processing 
operation, said method corrprising: 

causing an interface definition converting pro- 
gram to convert an interface ddinition desaip- 
tion described in an interface defnition 
language to thereby generate a client stub (1c). 
a server skeleton (2s) and a routing program 
(1r.2r). 

said interface definition description including 
one or more of a method definition description 
of data necessary for said predetermined 
processing operation, and a processing result, 
and a message deswiption specifying a format 
of the message to be sent in response to said 
method def initk)n description, 
said client stub being called to cause said client 
object to send the message, 
said server skeleton including a server registra- 
tion method for storing, in a routing information 
memory routing information for specifying the 
fbmnat of said message whk:h said server 
object itself can process when started and also 
including a method for describing saki prede- 
tern^ned processing operation to be ^ecuted 
when said server object receives the message, 
and 

sakf routing program judging whether or not the 
processing of said server object associated 
with said routing information of said message is 
possible through comparison between saki 
message and said routing information. 

2. An inter-objed communication method wherein a 
client object (10) operating on either one of a plural- 
ity of computers (1,2,3) in a network (8) or on a sin- 
gle computer sends a message to a server object 
(20) operating on the same or another computer to 
execute a predetermined processing operation, 
saki metiiod comprising the steps of: 
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storing a client stub (1c). a server skeleton (2s) 
and a routing program (1r,2r) generated based 
on an interface definition description; 
when said server object is started, calling a 
server registration method and storing routing s 
information in a routing information memory 
(3m) to cause said client object to call said cli- 
ent stub to send the message and to hold said 
sent message in a send message queue 
(1m1,2m1); io 
causing a router (12,22) to extract the message 
from said send message queue, to determine a 
send destination object in accordance with said 
routing program and to add the received mes- 
sage in a receive message queue (Im2.2m2) is 
associated with said send destination object; 
and 

causing said server skeleton to extract the 
message from said receive message queue 
and causing said server object to execute said 20 
predetermined processing operation of the 
message extracted k>y said server skeleton. 

3. A method for converting an interface definition 
desaiption as set forth In claim 1, wherein said 
routing program adds a queueing option description 
including a message maximum number designation 
arxl a queueing time designation to a message 
description of said interface definition description, 
compares said message and said routing informa- 30 
tion to judge whether or not the processing opera- 
tion by said server object associated with sad 
routing infomnation of said message is possible 
and. in the case of presence of said message max- 
imum number designation, performs said queueing 35 
option judging operatbn. 

4. An inter-object communication method as set forth 
in claim 2. wherein saki router keeps the message 
extracted from said send ntessage queue in a tern- 40 
porary keep message queue, and when another 
message has the same contents as said kept mes- 
sage, the router integrates the messages into a sin- 
gle message, and when the nunt^er of messages 
within the temporary keep message queue exceeds 46 
said message maximum number or when said 
queueing time elapses after said message is 
queued, the router adds said message to a receive 
message queue associated with saki send destina- 
tion object. so 

5. A method for converting an interface definition 
desaiption as set forth In claim 1. wherein, in place 
of said routing program, a custom routing program 

Is generated which compares said message and ss 
said routing information to judge whether or not the 
processing operation by said server object associ- 
ated with said routing information of said message 
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is possible and performs said matching option judg- 
ing operation. 

6. An inter-object communication method as sd forth 
in claim 2. further comprising the steps of: 

combining said client stub, said server skeleton 
and said routing program into a single server 
object and storing sakJ service object in a serv- 
ice object memory; 

before saki client object sends a message, 
extracting sakJ server object from said sen^k;e 
object memory to call sakI client stub; 
before sakJ router determines said send desti- 
nation object, extracting said server ot)ject from 
sakJ service obfect memory to call sakJ routing 
program; and 

at the time of starting said server object, 
extracting said server object from sakJ s&rAce 
object memory to call saki server skeleton. 
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// INTERFACE DEFINITION 
interface DigitalLlbrary { 



// NATIVE METHOD DESCRIPTION 

native boolean isSupportCategory (in string keyword) ; 



40 



41 



//METHOD DEFINITION 1 

void search (in string keyword) throws InvalidParameterException 



// MESSAGE DESCRIPTION 
message { 

pattern = "search Skeyword"; 



//QUEUING OPTION DESCRIPTION 
maximum = 100 ; 
timeout = 60 ; 



> 



// MATCHING OPTION DESCRIPTION 
match { 

if (isSupportCategory ($keyword) ) 

return SUCCESS ; 
else 

return FAILURE ; 

>: 



410 



4100 



411 



//METHOD DEFINITION 2 



42 
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#include "MessagingLibrary .h" 

// CLIENT STUB CLASS DECURATION (DigitalLibrary . h) 

class DigrtalLibrary : ClientStub { 

public: 



//MESSAGING METHOD DECLARATION 1 

void search (char* keyword) throw (InvalidParameterExcepllon) ; 



// MESSAGING METHOD DECLARATION 2 



• • • V-v 

}: 1cf12 



#lnclude "DigllalLibraty .h" 

// CLIENT STUB CLASS DEFINITION (DigitalLibrary . cpp) 



//MESSAGING METHOD DEFINITION 1 

void DigitalLibrary : : search (char* keyword) 

throw (InvalidParameterException) { 
if ( (l<eyword == NULL) 1 1 {'keyword == NULL) 

throw lnvalidPararneterException( ) ; 
char* message = new char [strlen(keyword) +8] ; 
'message = VO' ; 
strcpy (message, "search") ; 

sendMessage ("DigitalLibrary", strcat{message. keyword) ) ; 
delete message ; 

} 
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#inciucle "MessagingLibrary .h" 

// SERVER SKELETON CLASS DECLARATION (DigilalUbrarySkelton . h) 
dass DigitatLibrarySkelton : ServerSkelton { 
public : 



// REGISTRATION METHOD DECLARATION 
void register ( ) ; 



//MESSAGE HANDLER DECLARATION 1 
void search (char* keyword) ; 



// MESSAGE HANDLER DECLARATION 2 



2sf10 
2sf11 
2sf12 



}; 



#include "Dig italLlbrarySkelton h" 

// SERVER SKELETON CLASS DERNmON (DigilalUbrarySkelton. cpp) 



// REGISTRATION METHOD DEFINITION 
void DigitalLibrarySkelton : : register ( ) { 2sf20 

regjsterServer ("DigitalLlbrary") ; 

reglsterHar^dler ("search search) ; 

} 



// MESSAGE HANDLER DEFINITION 1 2sf21 
void DigitalLibrarySkelton ; : search (char* keyvirord) { 
/••'describe searching operation. **•/ 
} 

2sf22 



// MESSAGE HANDLER DEFINITION 2 



^2sf2 
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11 ROUTING PROGRAM CUSS DECLARATION (DigrtalLibraryRouter . h) 
class DlgitalLlbraryRouter : RoutingMethod { 

public : 

static char* InterfaceName; 




// QUEUING OPTION VARIABLE DECLARATION 
static long maximum ; 

static long timeout ; 


1rf11 


//MATCHING METHOD DECLARATION 
Virtual boolean match (In siring message) ; 


1rf12 


}; 




#lnclude "DigitalLibraryRouter h" 

// ROUTING PROGRAM CLASS DEFINITION (DigitalUbraryRouter . cpp) 
static char*DigjtalLlbraryRouter : : InterfaceNames'DlgjtalLibrary" : 


//EXTERNAL METHOD DECLARATION 

extern boolean isSupportCategory (In string keyword) ; 


1rf20 


//QUEUING OPTION VARIABLE DEFINITION 
static long DigitalLibraryRouter : : maximum = 100 ; 
static long DigitalLibraryRouter : : timeout = 60 ; 


1rf21 

1rf22 

( 


//MATCHING METHOD DEFINITION 
boolean DigitalLibraryRouter : : match (in string message) { 
if (IRoutingMethod : : match("search message) ) 
return false ; 

if (lsSupportCategory(message) ) { 
return true ; 
else 

return false ; 

} 



^1rf2 
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